Skip to content

T8099: strongswan: 6.0.6 + Post quantum options#5267

Open
hedrok wants to merge 1 commit into
rollingfrom
T8099-strongswan-6.0
Open

T8099: strongswan: 6.0.6 + Post quantum options#5267
hedrok wants to merge 1 commit into
rollingfrom
T8099-strongswan-6.0

Conversation

@hedrok

@hedrok hedrok commented Jun 10, 2026

Copy link
Copy Markdown
Contributor

Change summary

  • Update required strongswan version to 6.0.6
  • Add options for mlkem*

Types of changes

  • Bug fix (non-breaking change which fixes an issue)
  • New feature (non-breaking change which adds functionality)
  • Code style update (formatting, renaming)
  • Refactoring (no functional changes)
  • Migration from an old Vyatta component to vyos-1x, please link to related PR inside obsoleted component
  • Other (please describe):

Related Task(s)

Related PR(s)

How to test / Smoketest result

Setup IPSEC, but use

set vpn ipsec ike-group MyIKEGroup proposal 1 dh-group '34'

Then check

vyos@r1:~$ show vpn ike sa
Peer ID / IP                            Local ID / IP
------------                            -------------
10.1.0.1 10.1.0.1                       10.1.0.2 10.1.0.2

    State  IKEVer  Encrypt      Hash          D-H Group      NAT-T  A-Time  L-Time
    -----  ------  -------      ----          ---------      -----  ------  ------
    up     IKEv2   AES_CBC_128  HMAC_SHA1_96  ML_KEM_768     no     37      27557

Checklist:

  • I have read the CONTRIBUTING document
  • I have linked this PR to one or more Phabricator Task(s)
  • I have run the components SMOKETESTS if applicable
  • My commit headlines contain a valid Task id
  • My change requires a change to the documentation
  • I have updated the documentation accordingly

* Update required strongswan version to 6.0.6
* Add options for mlkem*
@coderabbitai

coderabbitai Bot commented Jun 10, 2026

Copy link
Copy Markdown

Review Change Stack

📝 Walkthrough

Summary by CodeRabbit

  • New Features

    • Added post-quantum ML-KEM cryptographic key exchange options (512, 768, and 1024-bit variants) for IPsec VPN configurations.
  • Chores

    • Updated strongSwan VPN backend dependency requirement to version 6.0.6 or later.

Walkthrough

Adds post-quantum ML-KEM Diffie-Hellman groups (dh-group33, dh-group34, dh-group35) to IPsec configuration. Updates strongSwan dependency to 6.0.6, extends schema validation and completion lists for ESP PFS and IKE proposals, and updates cipher template lookups.

Changes

ML-KEM Post-Quantum IPsec Group Support

Layer / File(s) Summary
strongSwan 6.0.6 dependency
debian/control
strongSwan, strongswan-swanctl, charon-systemd, plugin packages, and python3-vici dependencies bumped from >= 5.9.11 to >= 6.0.6.
ESP PFS and IKE DH group schema extensions
interface-definitions/vpn_ipsec.xml.in
ESP PFS group options (esp-group/pfs) and IKE proposal DH groups (ike-group/proposal/dh-group) now accept dh-group33 (mlkem512), dh-group34 (mlkem768), and dh-group35 (mlkem1024); completion lists, valueHelp descriptions, and validation regex updated accordingly.
Cipher template lookup mappings
python/vyos/template.py
get_esp_ike_cipher() pfs_lut lookup table extended with dh-group33→mlkem512, dh-group34→mlkem768, dh-group35→mlkem1024 mappings.
🚥 Pre-merge checks | ✅ 4 | ❌ 1

❌ Failed checks (1 warning)

Check name Status Explanation Resolution
Docstring Coverage ⚠️ Warning Docstring coverage is 0.00% which is insufficient. The required threshold is 80.00%. Write docstrings for the functions missing them to satisfy the coverage threshold.
✅ Passed checks (4 passed)
Check name Status Explanation
Title check ✅ Passed Title directly corresponds to the main changes: updating strongswan to 6.0.6 and adding post-quantum ML-KEM options.
Description check ✅ Passed Description clearly outlines the changes (strongswan version update, ML-KEM options), provides test instructions, and links to related tasks/PRs.
Linked Issues check ✅ Passed Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check ✅ Passed Check skipped because no linked issues were found for this pull request.

✏️ Tip: You can configure your own custom pre-merge checks in the settings.

✨ Finishing Touches
✨ Simplify code
  • Create PR with simplified code
  • Commit simplified code in branch T8099-strongswan-6.0

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

Comment @coderabbitai help to get the list of available commands and usage tips.

@mergify mergify Bot added the rolling label Jun 10, 2026
@mergify mergify Bot assigned hedrok Jun 10, 2026
@github-actions

Copy link
Copy Markdown

❌ Typos detected in PR (8 found)

File Typo Suggestion
debian/control:386 nd and
python/vyos/template.py:127 formater formatter
python/vyos/template.py:132 formater formatter
python/vyos/template.py:144 formater formatter
python/vyos/template.py:145 formater formatter
python/vyos/template.py:153 formater formatter
python/vyos/template.py:174 formater formatter
python/vyos/template.py:551 ede edge

@coderabbitai coderabbitai Bot left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🧹 Nitpick comments (1)
python/vyos/template.py (1)

509-512: ⚡ Quick win

Add unit coverage for new ML-KEM DH-group mappings.

get_esp_ike_cipher() now maps dh-group33/34/35, but existing template tests only assert legacy groups. Add assertions for mlkem512/mlkem768/mlkem1024 render output to lock the cross-file contract.

Proposed test addition
--- a/src/tests/test_template.py
+++ b/src/tests/test_template.py
@@
     def test_cipher_to_string(self):
         ...
+
+    def test_cipher_to_string_mlkem_groups(self):
+        data = {
+            'proposal': {
+                '10': {'encryption': 'aes256gcm128', 'hash': 'sha256'}
+            }
+        }
+
+        data['pfs'] = 'dh-group33'
+        self.assertIn('mlkem512', ','.join(vyos.template.get_esp_ike_cipher(data)))
+
+        data['pfs'] = 'dh-group34'
+        self.assertIn('mlkem768', ','.join(vyos.template.get_esp_ike_cipher(data)))
+
+        data['pfs'] = 'dh-group35'
+        self.assertIn('mlkem1024', ','.join(vyos.template.get_esp_ike_cipher(data)))
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@python/vyos/template.py` around lines 509 - 512, The template added mappings
for 'dh-group33/34/35' -> 'mlkem512/mlkem768/mlkem1024' in the mapping used by
get_esp_ike_cipher, but the template unit tests still only assert legacy DH
groups; update the template tests that validate ESP/IKE cipher rendering to
include assertions that inputs using dh-group33, dh-group34, and dh-group35
produce mlkem512, mlkem768, and mlkem1024 in the rendered output respectively so
the cross-file contract is locked. Locate the mapping in template.py (the
dh-group33/34/35 entries) and the test(s) that call get_esp_ike_cipher or render
the template, and add three assertions covering those new mappings.
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

Nitpick comments:
In `@python/vyos/template.py`:
- Around line 509-512: The template added mappings for 'dh-group33/34/35' ->
'mlkem512/mlkem768/mlkem1024' in the mapping used by get_esp_ike_cipher, but the
template unit tests still only assert legacy DH groups; update the template
tests that validate ESP/IKE cipher rendering to include assertions that inputs
using dh-group33, dh-group34, and dh-group35 produce mlkem512, mlkem768, and
mlkem1024 in the rendered output respectively so the cross-file contract is
locked. Locate the mapping in template.py (the dh-group33/34/35 entries) and the
test(s) that call get_esp_ike_cipher or render the template, and add three
assertions covering those new mappings.

ℹ️ Review info
⚙️ Run configuration

Configuration used: Repository YAML (base), Central YAML (inherited), Organization UI (inherited)

Review profile: CHILL

Plan: Pro

Run ID: b1ba7dd3-8319-430a-876b-3352af7196b2

📥 Commits

Reviewing files that changed from the base of the PR and between aee3754 and e71c0c7.

📒 Files selected for processing (3)
  • debian/control
  • interface-definitions/vpn_ipsec.xml.in
  • python/vyos/template.py
🔗 Linked repositories identified

CodeRabbit considers these linked repositories for cross-repo context during reviews:

  • ansible/ansible (manual)
📜 Review details
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (4)
  • GitHub Check: build_iso
  • GitHub Check: codeql-analysis-call / Analyze (python)
  • GitHub Check: Mergify Merge Protections
  • GitHub Check: Summary
🧰 Additional context used
📓 Path-based instructions (1)
**/*.py

📄 CodeRabbit inference engine (AGENTS.md)

**/*.py: Python code must target Python 3.11 or higher
Prefer storing Jinja2 templates as discrete files under data/templates/ rather than inline Python strings
Use ruff (version 0.6.4), darker, pylint W0611, and Jinja2 lint for linting; configuration via ruff.toml and nose2.cfg at repository root

Files:

  • python/vyos/template.py
🔍 Remote MCP

Excellent. I have gathered sufficient context about strongSwan 6.0.x and ML-KEM support. Let me search for information about the specific Diffie-Hellman group numbering (dh-group33, dh-group34, dh-group35) to understand the mapping to ML-KEM variants.The search didn't directly return the IANA registry mapping. Let me search more specifically for ML-KEM group numbers.I have gathered comprehensive information about strongSwan 6.0.x, ML-KEM support, and related technical context. While I found information about ML-KEM in general and its IANA codepoints for TLS (0x0200, 0x0201, 0x0202), the search results don't provide the specific IANA registry mapping for dh-group33/34/35 in IKEv2. However, I have sufficient context to provide a meaningful summary. Let me compile the review context now.

Additional Relevant Context for PR #5267 Review

StrongSwan 6.0.x ML-KEM Support

StrongSwan 6.0.0 brings support for multiple classic and post-quantum key exchanges and supports ML-KEM. ML-KEM (FIPS 203) support has been added via Botan 3.6.0+ (botan plugin), wolfSSL 5.7.4+ (wolfssl plugin), AWS-LC 1.37.0+ (openssl plugin), and the new ml plugin. Additionally, ML-KEM is now supported via OpenSSL 3.5+ by the openssl plugin in StrongSwan 6.0.2.

Post-Quantum Key Encapsulation (ML-KEM)

The Module-Lattice-Based Key-Encapsulation Mechanism (ML-KEM, FIPS 203) is a mechanism to establish a shared secret that is believed to be secure even against adversaries with a quantum computer, with keywords for ML-KEM-512, ML-KEM-768 (3), and ML-KEM-1024 (5) being mlkem512, mlkem768 and mlkem1024, respectively. NIST recommends using ML-KEM-768 as the default parameter set, as it "provides a large security margin at a reasonable performance cost."

RFC 9370 - Multiple Key Exchanges in IKEv2

Support for multiple IKEv2 key exchanges (RFC 9370) allows up to seven additional key exchanges (classic or post-quantum) to establish key material when negotiating IKE and/or Child SAs. In proposals, additional key exchange methods are configured with a keX_ prefix, where X is a number between 1 and 7.

Performance Considerations

ML-KEM outperforms classic DH groups, with ML-KEM-768 faster than the fastest ECP group (DH group 19/ECP 256), and ML-DSA-65 certificate authentication having similar performance with RSA2048 certificates.

Security Against Quantum Threats

A Cryptographically Relevant Quantum Computer would pose a threat to current public key establishment algorithms, allowing "harvest-now-decrypt-later" attacks where encrypted communications using (EC)DH could be decrypted in the future after a CRQC became available. ML-KEM can be used as a quantum-resistant key exchange in IKEv2, and is believed to be infeasible to break, even by adversaries with a CRQC.

Implementation Requirements

Support for PQC algorithms in strongSwan is available only from version 6.0.0 onwards, which aligns with the PR's requirement to upgrade to strongSwan 6.0.6.

🔇 Additional comments (2)
debian/control (1)

311-318: LGTM!

interface-definitions/vpn_ipsec.xml.in (1)

182-182: LGTM!

Also applies to: 276-287, 293-293, 476-476, 566-577, 579-579

@github-actions

Copy link
Copy Markdown

CI integration ❌ failed!

Details

CI logs

  • CLI Smoketests ❌ failed
  • CLI Smoketests (interfaces only) ❌ failed
  • Config tests ❌ failed
  • RAID1 tests ❌ failed
  • CLI Smoketests VPP ⏭️ skipped
  • Config tests VPP ⏭️ skipped
  • TPM tests ⏭️ skipped

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Development

Successfully merging this pull request may close these issues.

2 participants